What is Design System?

So, ‘Design System’ is an entity of project deliverables which includes several logical groupings which are provided either by a UX or a UI designer because they both cover pretty much the same cases but only at the different stages of the product’s creation. It could be delivered as webpages within a product or as a separate product’s documentation, also it could be done as a Sketch or Figma files with access through the different ways such as Sketch Cloud, Abstract, InVision, or Figma Share. Firstly, I’m going to tell you about the structure of the ‘Design System’ and after this, I’ll try to explain why and how ‘Design System’ could migrate from UX and UI needs to a front-end team.

In general, the ‘Design System’ includes information about the components of a project and their behavior. Components could be created in different ways, for example for UX designers it’s important to use them as elements with low or mid-fidelity without any strict reference to the color or style guide, or even typography. The main purpose of this ‘Design System’ for UX designers is to use components consistently within a product designing process. From the UI perspective, it is important to use components as ones with high-fidelity. In this case, elements must be stacked strictly to style guides and typography, because it will be an example during markup.

Another significant line of ‘Design System’ for both casts of designers is the behavior of the components. It could be provided as text documentation with components described by specific use-cases or job-stories for each component, or as a visual interpretation that is more common nowadays.

And one more important point about the ‘Design System’ within components is that it must follow an ‘Atomic Design’ pattern. The understanding of this statement makes the life of your front-end team easier. Maintaining a clear dependence of the nesting of one component into another will make it possible to build it in the most organized way and it also will make easier the implementation of interface.

Besides, in some cases ‘Design System’ may contain the foundation pages which are related to business values, product goals or product purposes — that are helpful during the onboarding process for new team members. Also, as a rule, the Design System must contain the ‘Get Started’ page which explains all basics and best practices of components library and how to use the style guides, additional description of identity elements and ways of its applying.

That is briefly about the ‘Design System’ as an entity within a product design building.

Common use cases within a work process

Furthermore, I’d like to explain how to introduce the ‘Design System’ in the work process. Let’s say we have three cases from real life: first one when company gets a project from scratch, the second one when it comes on the user experience stage as a bench of wireframes which need to be improved and verified with a further user interface implementation, and the third one is when we transfer the project from design stage to a development team.

Case 1

In case when the team took a new design project from scratch and they have reached the ‘Prototype’ phase, the UX and UI designers should find out all basic components that will be used within the project accordingly to documentation. After it had been done, all components should be added to the component’s library file and no matter what software you preferer to use. Apparently, on this stage, the first version of the library will have low-fidelity until the solutions take approvals from the customer’s side, after which it is possible to transfer components to UI designer for further improvements. After the file would be updated by hi-fidelity components and all related information about their behavior, the link to the file must be provided to a front-end team with relevant explanations of why this file is needed and how it should be used on the ‘Get Started’ page. The sum-up of this example is that UX and UI designers should work with the ‘Design System’ together but consequently because each change in solution would be cheaper on the stage of UX but not at UI and furthermore after the markup.

Case 2

So, another case is when the design team takes a project with user experience solutions and this solution must be validated with further user interface implementation. Should a UX designer be involved in for creating a ‘Design System’ on this stage? Surely, he or she should not. UX specialist should do what he is supposed to do according to his primary tasks. Namely he is supposed to improve and validate as in this specific case. The Design System activities should be solved by a UI specialist because the project solution already exists. And even if in the worst case the interface fails testing in some user scenarios, it will not change the presence of the main components and their behavior in it. In this case, all improvements in terms of user experience will be carried out by the UX designer, and all components that require updating in the design system will be implemented by the UI designer.

The sum-up of this case is that both designers are doing their own part of business separately from each other but in one common direction.

Case 3

And the last case that will help to understand how to integrate the Design System into the development process. Just saying that it is an important thing is not enough. Developers must be motivated by the purpose that ‘Design System’ could give them. The front-end team should understand how exactly they will use the materials provided by the designers to cover their front-end and mark-up goals. And here are a couple of tips. The first one is a simple team meeting which should be directed to the synchronization of knowledge between frontend and design teams. Namely, it is necessary to agree on the consistency of the name and styles of components, to clarify all the behaviors of elements within the system, the types of user interaction with the interface and the interface with databases, in order to avoid decisions that will be difficult to implement. Look for approaches and solutions that satisfy the capabilities of the team which you workwith, do not insist only on your point of view and lobby your interests.